Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix CC detection #334

Merged
merged 6 commits into from
Jun 20, 2023
Merged

Fix CC detection #334

merged 6 commits into from
Jun 20, 2023

Conversation

anbe42
Copy link
Contributor

@anbe42 anbe42 commented Jun 11, 2023

The recent clang detection improvements broke getting a non-clang compiler from the kernel config.
Also move .kernelvariables parsing to prepare_build() where the other CC handling is.
On Debian there is no need for gcc, the header package has the required compiler dependency.

We had an interesting bug report on Debian (https://bugs.debian.org/1036033) where a broken rpm shim caused weird errors in dkms after a module was added and built with an empty $arch. So error out early if $arch cannot be determined, before misplacing stuff in /var/lib/dkms.

PS: Debian 12 (bookworm) was released yesterday, but there is no container image, yet, otherwise I would have added that to the matrix.

@evelikov
Copy link
Collaborator

Thank you and congrats on the Debian 12 release. Looking forward to a new container once it becomes available.

Will check this PR later today/tomorrow, but as a whole can you glance at #298 and comment on it. Do you see it working (reliably enough) for Debian, can we nuke .kernelvariables? Thanks in advance.

dkms.in Show resolved Hide resolved
@@ -61,7 +61,7 @@ jobs:
if: matrix.distro.name == 'debian'
run: |
apt-get update -q
apt-get install -qy gcc make linux-headers-amd64 linux-image-amd64 openssl
apt-get install -qy make linux-headers-amd64 linux-image-amd64 openssl
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting - Arch and Fedora (IIRC) don't pull the compiler stack, when the headers are installed.

Should we do the same change in the Ubuntu case below?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already tried, the gcc dependency is required at least for older Ubuntu releases.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack, please mention that in the commit message. For non Debian/Ubuntu experts such variations are non-obvious. Thanks

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

jfyi @xnox is the above variation, something Ubuntu team is willing to address? I don't have a strong opinion, just making sure devs in both distros are aware.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

even i don't know or understand if and when and why we have compiler depedency. i think in ubuntu we add "Package: dkms Depends: gcc" because we don't have dependency from headers to the compiler either (similarish to fedora). But we also have different compilers used for different kernels, thus maybe our headers should pull in correct compiler in.....

dkms.in Show resolved Hide resolved
export CC="$cc"
export KERNEL_CC="$cc"
fi

if grep -q 'CONFIG_CC_IS_CLANG=y' "${kernel_config}"; then
Copy link
Collaborator

@evelikov evelikov Jun 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The hunk was removed by @hadogenes with 4729aef. *Reintroducing it seems correct at a glance.

@hadogenes can you confirm this doesn't regress on your end? Which Suse variant/version are you using - SLES, Leap, Tumbleweed? Thanks

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clang detection is probably wrong if versioned clang-xx is to be used, but as long as we don't have a clang compiled kernel in Debian, I'm not going to investigate

@anbe42 anbe42 force-pushed the fix-CC-detection branch 4 times, most recently from 4e357f1 to d9c94ce Compare June 12, 2023 12:24
where the .config based compiler detection happens,
ensures that the compiler is set for PRE_BUILD
@anbe42
Copy link
Contributor Author

anbe42 commented Jun 13, 2023

Will check this PR later today/tomorrow, but as a whole can you glance at #298 and comment on it.

Will probaly need to be rebased after the current fixes got in. Will check in depth later.

Do you see it working (reliably enough) for Debian, can we nuke .kernelvariables? Thanks in advance.

I'd like to keep .kernelvariables for supporting older packaged kernels, but it should be remodeled and only used as a fallback if we cannot get the information from .config

Debian (but not Ubuntu) builds its kernels with a versioned compiler
binary (gcc-XX) and the linux-headers-* packages depend on that compiler
if for some reason $arch cannot be determined (e.g. due to a broken rpm
shim on distributions using a different package manager), dkms will
happily build a module, placing state info in
/var/lib/dkms/$module/$version/$kernel//, but that subsequently causes
errors because the module is not considered to be installed and at the
same time cannot be removed any more

Before:

sid# dkms status
sid# ln -s /bin/true /usr/bin/rpm
sid# dkms add dkms_test/1.0
Creating symlink /var/lib/dkms/dkms_test/1.0/source -> /usr/src/dkms_test-1.0
sid# dkms status
dkms_test/1.0: added
sid# dkms build -k 6.1.0-9-amd64 dkms_test/1.0
Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j16 KERNELRELEASE=6.1.0-9-amd64 -C
/lib/modules/6.1.0-9-amd64/build M=/var/lib/dkms/dkms_test/1.0/build...
Signing module /var/lib/dkms/dkms_test/1.0/build/dkms_test.ko
Cleaning build area...
sid# dkms status
dkms_test/1.0: added
sid# dkms build -k 6.1.0-9-amd64 dkms_test/1.0
Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub
Error! This module/version has already been built on: 6.1.0-9-amd64
Directory /var/lib/dkms/dkms_test/1.0/6.1.0-9-amd64/ already exists. Use
the dkms remove function before trying to build again.
sid# dkms status
dkms_test/1.0: added
sid# dkms remove -k 6.1.0-9-amd64 dkms_test/1.0
Module dkms_test 1.0 is not installed for kernel 6.1.0-9-amd64 ().  Skipping...
Module dkms_test 1.0 is not built for kernel 6.1.0-9-amd64 ().  Skipping...
sid# dkms status
dkms_test/1.0: added
sid# dkms remove dkms_test/1.0 --all
sid# dkms status
dkms_test/1.0: added
sid# find /var/lib/dkms/dkms_test/1.0/
/var/lib/dkms/dkms_test/1.0/
/var/lib/dkms/dkms_test/1.0/6.1.0-9-amd64
/var/lib/dkms/dkms_test/1.0/6.1.0-9-amd64/module
/var/lib/dkms/dkms_test/1.0/6.1.0-9-amd64/module/dkms_test.ko
/var/lib/dkms/dkms_test/1.0/6.1.0-9-amd64/log
/var/lib/dkms/dkms_test/1.0/6.1.0-9-amd64/log/make.log
/var/lib/dkms/dkms_test/1.0/6.1.0-9-amd64/log/.config
/var/lib/dkms/dkms_test/1.0/source

After:

sid# dkms status
sid# ln -s /bin/true /usr/bin/rpm
sid# dkms add dkms_test/1.0
Error! Could not determine architecture.
sid# echo $?
12

to manually recover from the bug use
  rm -rf /var/lib/dkms/$module/$version
and add/build/install the module(s) again
Copy link
Collaborator

@evelikov evelikov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the updates and feedback regarding the other PR.

This series is good to land, but let's give @hadogenes a few days to a week to reply. I had a quick try at adding Suse CI but it seems fiddly, so could not personally test the relevant change for regressions.

@evelikov evelikov merged commit 4682876 into dell:master Jun 20, 2023
20 checks passed
@anbe42 anbe42 deleted the fix-CC-detection branch December 6, 2023 08:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants